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5 ARRANGEMENT, SYSTEM AND METHOD RELATING TO EXCHANGE OF 
INFORMATION 

BACKGROUND 

The present invention relates to an arrangement for handling 
10 exchange of information/messages between an information 
w requesting side and an information providing (information 

holding) side. The information requesting side comprises an 

information requesting application and the information providing 
yj 'side comprises an information providing application. The 
a 4f5 invention also relates to a data communication system with a 
f plurality of applications which e.g. may request information 

from each other, i*e, request access to information residing on 
HI other applications. Still further the invention relates to a 
J method of exchanging information between applications* 
go 

There is no satisfactorily functioning technique known for the 
situation when an information requesting side requests access to 
information residing on an information providing side, or when 

25 an application requests information from a providing side, 
particularly not for queries to dynamic information. All known 
techniques strongly depend on the implementational structures 
such as used tables, of the information holding means comprised 
by, or associated with, an application. SQL (Structured Query 

30 Language) is one such technique which is particularly suitable 
when one or more pieces of information, which match a specific, 
given criterion, are to be searched for SQL requires input data 
which is highly specified, presupposing a good knowledge of the 
structure of databases and relations. It is not possible to 

35 dynamically, using dynamical input parameters, get the 



appropriate dynamical answer. Generally, when access to 
information is requested over an IP-based data communication 
network, several TCP (Transmission Control Protocol) connection 
setups are required. Particularly, known systems can not readily 
be adapted to also satisfy the needs of an end user to protect 
data contained in personal profiles located throughout a 
network, at different application or information providing 
sites. Particularly, there is actually no simple way for an end 
user to control which information should be released to whom 
etc. in a user friendly way. Also, more generally, there is no 
simple and user friendly procedure known through which dynamic 
information or messages can be exchanged between two 
applications. There is also no satisfactorily functioning 
solution available for inter-business communication when there 
is a desire not to reveal the structure etc. of used data bases. 

SUMMARY • 

What is needed is therefore an arrangement capable of 
efficiently handling exchange of information/messages between an 
information requesting side and an information providing or 
holding side. An arrangement is also needed which is easy to use 
and which is uncomplicated as to its functioning. An arrangement 
is particularly needed, which can be used for queries relating 
to dynamic information. An arrangement is also needed which 
functions independently of implementation, structure and 
relations of any information holding means. Most specifically an 
arrangement as referred to above is needed which duly can take 
personal privacy into consideration, i.e. which at the same time 
may support control of access to data within end user personal 
profiles . 

An arrangement as initially referred to is therefore suggested/ 
in which an agreement is given or created between an information 
requesting application and an information providing application, 
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through which agreement it is specified what information should 
be exchangeable between the requesting and the providing 
applications respectively. The agreement may relate to exchange 
of information in one direction, or in both directions between 
5 the parties. The agreement is represented through a form to be 
filled in by, and communicated between, the requesting and 
providing applications, in both directions relating to 
requesting data and providing/setting data. A generic markup 
language is used for creation and communication of said form, in 
10 a most advantageous implementation the generic markup language 
is XML (Extensible Markup Language) . An agreement between two 
»U parties particularly comprises a DTD (Document Type Definition) 
*y and it will in the following be referred to as a DTD agreement, 
j; i.e. an agreement specifying which data or what kind of data 
1%J that is allowed to be exchanged between the two parties. The 
J**? form particularly comprises an XML (node) tree tagged with 
J"" information about data to be "set" or "get", and the requested 
data itself, if applicable. 

2m A DTD describes a model of the structure of the content in an 
. M XML document. The model specifies the elements which have to be 
provided, which elements that are optional, which their 
attributes are and how they could be structured in relation to 
each other. As a comparison, HTML (Hyper Text Markup Language) 
25 only has one DTD; by using XML, it becomes possible to create 
proprietary DTD: s for the user applications which provide full 
control of the process of controlling the content and structure 
of an XML document created for an application. A DTD is 
associated with an XML document by means of a document type 
declaration. A Document Type Definition, DTD, is here an XML 
description of the content model of the types (or classes) of 
the documents, A document type declaration is a submission in an 
XML file to explain that a certain DTD belongs to a document. 
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Particularly the form comprises an XML (node) tree with queries 
for example in the form of attributes which may be given values 
as the form is filled in- In a particular implementation the 
attributes comprise one or more of "from", "get", "null" 
"error", "set", the significance of which should be clear from 
the reading. 

In one implementation the tagged XML form comprises an XML 
string. In an alternative implementation the tagged XML form 
comprises an XML object (a DOM node tree object) . DOM is an 
abbreviation of Document Object Model as defined by W3C, World 
p Wide Web Consortium. DOM is a standardized tree based application 
;Jj programming interface (API) for XML. The object form presupposes 
m the Provisioning of transforming/parsing means in the respective 
l|p applications, i.e. the requesting application and the 
J2 information providing application, for transforming XML objects 
yg to XML strings using an XSL transformation style sheet (XSLT) 
L and to P arse an XML string to an XML object* In particular 
y, implementations server means are associated with the requesting 
2 ?y and Providing applications respectively. An XML string is 
jij "visible" to the user, i.e. it can be read, as opposed to the 
y, XML object which is "invisible", i.e. not readable. 

According to the invention the providing application comprises 

2 5 means for converting a received XML form query to a database 

call, e.g. of SQL format, to fetch the requested information, 
which, when retrieved is entried/f illed in on the form for 
retransmittal to the requesting application (if it is a pull ox 
"get" (retrieve) operation) . An application may particularly 

3 0 function both as a requesting and a providing application. 

However, for a pair of applications, an agreement may also be 
based on the assumption that one of the applications always acts 
as a requester and the other always acts as a provider, or 
holder . 
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Preferably the XML form is entirely independent of the 
structural implementation of any information holding/providing 
database or similar, as well as of any application. 

5 

In a most advantageous implementation validating means are 
provided for validation of a request. The validating means may 
comprise end user controlled, user unique DTD : s stored in 
information holding means. A filled-in XML form from a 
10 requesting application may be validated against the appropriate 

f1 end user unique DTD to establish whether the request is allowed 

yp or not. 



j; Particularly a "general" or basic DTD is given for the 
l&l agreement, which may be used to build a basic XML form. Such a 
basic DTD may be applicable for exchange of information between 
*i applications relating to similar services, i.e. the same basic 
■f7 XML form may be used for a first application exchanging 
fy information with several second applications of the same type or 
2in category, In case validation is implemented, the DTD should be 
y[ transmitted with the XML form, otherwise the inclusion of the 
DTD may be optional- Also for validation procedures it is 
however not always mandatory to include the DTD. 

2 5 In a most advantageous implementation, including validation, 
access means (e.g. plug-in server means) are provided in, or 
associated with, the respective requesting and providing 
applications. These access means are in communication with one 
or more central protection server means, and together therewith 

30 they constitute a personal protection profile network. The 
central protection server means comprises, or communicates with, 
personal protection profile holding means. Particularly the 
personal protection profile holding means holds end user unique 
protection profiles specifying which data within personal 
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profiles that should be accessible/non-accessible to which 
applications. The end user protection profiles are preferably 
end user controlled and comprise user unique DTD:s. 

5 Particularly an application and its associated access means 
communicate by means of XML objects in XML transport objects, 
e.g. an XML node tree in an XML node tree container, e.g. using 
RMI (Remote Method Invocation) or CORBA™ ♦ The access means 
associated with a requesting application will particularly find 
10 a user unique DTD, i.e. a personal protection profile, in the 
central protection server means using information about the 
p general agreement (general or basic DTD) provided from the 
S requesting application, whereby the user unique DTD is validated 
gy against a filled-in XML form which is filled in to establish if 
15f- a request should be allowed or not. Particularly HTTPS (Hyper 
Q Text Transfer Protocol Secure) is used for communication between 
the access means of two communicating applications and for 
communication between either of the applications, or rather its 
jU associated access means, and the central protection server means 
2( S (also simply referred to as central server means) . Internet or 
;K any other appropriate IP-based network may be used. For 
yk communication between an access means and the central protection 
server means the XWL form has to be transported as an XML 
string. Also for communication between two access means the XML 
25 form has to be in the form of an XML (transport) string. 

The invention also provides a data communication system 
providing communication between a number of applications 
comprising and/or communicating with service/information/content 
providers or holding means holding end user personal profile 
data. Between intercommunicating pairs of applications, an 
agreement is setup or given to define what information should be 
allowed to be transferred between the applications, either 
unidirectionally, i.e. from one application to the other, or 
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bidirectionally, i.e. from the first application to the second 
and vice versa. Such agreements are stored in agreement 
information holding means. The agreements are represented in 
forms to be filled in and transferred between an information 
requesting application and an information providing application. 
A generic markup language is used for implementation, handling 
and communication of said forms. The generic markup language is 
particularly XML. The forms may comprise XML (node) trees tagged 
with information about data to be "set" or "get" (pushed or 
pulled) and, if applicable, (for pull requests) the requested 
data itself. The agreements particularly are produced in the 
=£! form of DTD : s . In one implementation agreements are held by the 
-v respective applications, between which an agreement has been 
f established, or by holding means associated with the respective 
l&y. applications. In an alternative implementation agreements are 
;S stored separately, or at a central location, or similar. 

tl In one specific implementation the system also comprises a 
■Fy personal profile protection network (on top of e.g. an IP-based 
2(f! network) . In a preferred implementation the personal profile 
^ protection network consists of access means associated with each 
respective application and central protection server means, 
comprising or communicating with information holding means. The 
information holding means may then comprise and coincide with 
25 said agreement holding means. Such a system is particularly 
advantageous in that it allows for, or shows one way of, 
enabling validation of data requests and concerned users. 



Particularly attributes are used in the XML (node) tree form, 
which attributes may be specified or not, i.e. given a value or 
not, which thus constitutes the filling in of the form. The XML 
form tagged in such a manner (XML tree with attributes and 
element data) , is communicated between applications as an XML 
string. The XML tree may in the applications (and their access 
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means, if such are provided for) be provided in the form of XML 
objects, e.g. XML DOM (Document Object Model) node trees. Then, 
however, transforming/parsing means have to be provided in the 
applications (or in access means associated therewith) for 
transforming an XML object (DOM node tree) to an XML string to 
make it transportable between applications (access means, access 
means and central server means), and for parsing an XML string 
to an XML object. 



In embodiments supporting validation, validating means comprise 
end user controlled, user unique DTD: s as personal protection 
0 profiles stored in the information holding means. An XML form 
.|j tagged ±n the appropriate manner, from a requesting application, 
m ^ s validated against the appropriate user unique DTD to 
I^f establish whether the request is allowed or not. Particularly, 
W for an a 9" reem ©nt, a general or basic DTD is given. If validation 
43 is implemented, the user unique DTD should preferably be 
included in the communication between requesting and providing 
|^ sides, otherwise the inclusion thereof is entirely optional. 

p The invention also discloses a method for exchanging 
J«* information/messages between an information requesting 
application and an information providing application having 
established an agreement to specify information that should be 

25 allowed to be transferred between the information requesting and 
information providing applications (either is one of the two 
applications always the requesting application and the other 
always the information providing application, or alternatively 
both applications may function as an information 

30 providing/requesting application) . The method comprises the 
steps of; producing, using a generic markup language, a form 
with elements and attributes, wherein the attributes are used to 
indicate elements to be filled with data (according to the 
agreement) ; transferring the form as filled- in with information 
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relating to requested data (push data or pull data) from the 
request application to the providing application; receiving the 
form at the receiving application; converting the request form 
to a database call; accessing the appropriate information 
5 holding site using a database call; for a request to get data 
(pull request) : filling in the form with the data retrieved from 
the information holding site; returning the form as filled-in to 
the requesting application. (If the request relates to setting 
data, the appropriate data, as given in the form, is instead set 
10 at the inf ormation holding site) . 

€3 The generic markup language particularly is XML, and the form 
w comprises an XML (node) tree comprising elements with XML 
J; attributes used to indicate elements to be filled with data 
according to the agreement. Particularly the DTD agreement 
S comprises a DTD which is used when producing the XML form. 

*~ The method in advantageous implementation also comprise the step 
j|| of; communicating the XML form tagged with information as an XML 

2{fp string- 
In one implementation the method comprises the step of; 
implementing the XML tree form as an XML DOM node tree object, 
then including the steps of; converting the XML DOM node tree 

25 object to an XML string in the respective requesting/providing 
applications for communication between said applications; 
parsing the XML string to a DOM node tree object in the 
providing application - 
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Alternatively the XML tree form is implemented as an XML string. 



The DTD agreement may be included in the XML string. In 
advantageous implementations the method includes the step of; 
validating the XML tree against a user unique DTD stored in for 



10 



10 



example personal protection profile holding means, and 
requesting/ providing information as allowed according to the 
outcome of the validation. Then the DTD agreement should 
preferably be included in the XML string, although not 
necessarily. 

It is an advantage of the invention that, when a query is 
produced, which should be responded to, the relevant information 
that is needed to find the answer is generated instantly. Also 
the reply is generated dynamically and momentarily subsequently 
the information is detected. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will in the following be further described, in a 
n °n-limiting manner, and with reference to the accompanying 
ly drawings, in which: 

Lk Fig. 1 is a first schematical illustration of two applications 
using an XML form for requesting and providing data, 

O Fig. 2 is a schematical illustration of an alternative 
embodiment in which an XML form is used for requesting 
and providing data, but wherein agreement information is 
stored externally, 

25 

Fig. 3 illustrates still another implementation, in which 
validation is performed by use of a personal profile 
protection network, 

3 0 Fig. 4 is a flow diagram describing the flow when the XML form 
is implemented as a DOM node tree object; 



Fig* 
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is a flow diagram describing an exemplary flow when the 
XML form is implemented as an XML string, and 



Fig. 6 is a flow diagram describing a procedure according to one 
embodiment: of the invention which supports a validation 
procedure . 

DETAILED DESCRIPTION 

Fig, 1 very schematically illustrates two communicating 
applications, here denoted requesting application A 10 and 
inf ormation providing application B 20. It is supposed that each 
application 10,20 comprises or communicates with agreement 
holders 30A,30B for holding information about agreements 
established between the respective applications. It is supposed 
that an agreement between two applications, here applications A 
and B, is stored in both respective applications . The agreement 
holder of an application may comprise a plurality of different 
agreements, e.g. one for each other application with which the 
concerned application has concluded an agreement, and defining 
which,, or what type of, information that is allowed to be 
exchanged between the respective pair of applications. In the 
figure it is illustrated that each respective application 
comprises an XML form handler, which actually comprises software 
(i.e. not necessarily specific means), for, using information 
about the agreement, creating an XML form to be filled in when a 
request Is sent- In this first embodiment it is supposed that 
application A 10 requests information from application B 20. 

The agreement established between applications A and B, as 
available in an information holder 3 OA, particularly in the form 
of a DTD (Document Type Definition) agreement, is used by the 
XML form handling functionality to create an XML form, e.g. in 
the form of an XML node tree with queries in the form of 
attributes to be given values in accordance with the specific 
request. Thus, when an XML form has been created, the attributes 
are given values, and the XML form tagged with information (in 
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the attributes and element data) , relating to the requested 
information, is transferred to application B 20 over an IP 
network, e.g. using HTTPS, as an XML transport file, e.g. as an 
XML string. 

In a preferred implementation the XML node tree comprises an XML 
DOM node tree. Alternatively the XML tree is implemented as an 
XML string. If the XML form is built as an object, 
transformation to an XML transport string is required for 
purposes of transportation. The XML form received in application 
B 20 be will transformed to a database call, here particularly 
in a transforming means. Particularly it is transformed to an 
SQL request, to access/fetch the data as indicated by the query 
from a database 23 holding the requested information. When the 
requested information has been retrieved from database 23, the 
form is filled in, particularly by giving the attributes and 
element data the appropriate values, i.e. according to the 
invention as retrieved from database 23. If the request instead 
concerns setting of data, the "requested" data is accessed by 
means of e*g* SQL, and data according to the attributes is set. 

The completed XML form is then returned to application A 10, and 
the form as filled-in may be presented to the user. However, 
this is merely a schematical illustration of the functioning; 
the main thing being that an XML form is given which comprises 
attributes to be given values both to define which information 
that is requested (for setting or getting purposes) and to 
contain the requested information (if relevant) when returned to 
requesting application. If the XML form is implemented as a 
string, no transformation/parsing means are required, except for 
the transformation (conversion) to a database call- If however 
the XML form is represented in the form of an XML DOM node tree, 
transformation means are required for purposes of transportation 
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between the applications (and parsing means for returning the 
form in string format to a DOM node tree. 

Fig. 2 schematically illustrates a somewhat different 
* 5 implementation in which a requesting application 10 0 requests 
information from a providing application 20q, between which 
applications lQ 0 ,20o an agreement has been established, it is here 
supposed that agreement information is stored in external 
agreement holder 30C in communication with both the requesting 
10 application 10 0 and the providing application 20q. Communication 
between the agreement holder 30C and the providing application 2 0 0 
y is here indicated through a dashed line, since when requesting 
5 application 10 0 requests information from the providing 
V application (or wants to access data on the providing/holding 
lffj side) , 20 0 there is no need for the providing application 20 0 to 
y fetch the agreement (at least not when no validation is required, 
but also then it is not necessarily needed according to 
advantageous implementations) . It is here supposed that agreements 
yk have been created in the form of Document Type Definitions DTD, It 
2(|S is supposed that the agreement between requesting application 10o 
Q and providing application 20 0 here is denoted DT D^ . When 
application 10 0 wants to get information from application 2Q 0 , DTDx 
is fetched and an XML DOM node tree object or an XML tree string 
is built in XML form handler* The attributes in the XML tree are 
25 given values (assigned) relating to requested data. Examples on 
attributes are "from", "get", "set", "null" ^ "error". 

In this application all embodiments are described with reference 
to implementations for retrieving (pulling) data from the 
30 providing side. The inventive concept is of course also applicable 
to the concept of pushing data, i.e. for setting data on a 
providing side or in an information holding site. 
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The XML form, if it is in form of a string, is, 
attributes have been given the appropriate values,, tran| 
the providing application 2 0 Q as an XML string, 
including DTD lw In the providing application 20 0 , in transforming 
means, i.e. software which not necessarily has to be provided in a 
"means", a transformation is performed to a database call, e*g* of 
SQL format, which call is forwarded to the databasi 23 0 * The 
requested data is subsequently returned to the providing 
application, and filled in on the XML form as values on the 
concerned attributes and element data The form returned to the 
requesting application as an XML string (optionally with a DTD 
included) ♦ In one advantageous implementation the XML tree form is 
implemented as an XML DOM node tree object. The object 
converted to a string for transportation from 
application A 10 to providing application B 20. The XML 



be parsed on the providing side by means of the DOM parser to be 
in object form, which generally facilitates the filling-in of the 
form. However, for retransmittal to the requesting application, 
the XML DOM node tree has to be transformed to an XML node string. 
It is also possible to implement the XML form as an 
without using it in object form. 



has to be 
requesting 
string may 



Fig. 3 describes a specific implementation in 
validation procedure as described in the patent appl 
SYSTEM AND A METHOD RELATING TO ACCESS CONTROL" filed 
October 12, 2001 and the content of which herewith is 
herein by reference. With reference to Fig. 3 it is s 
an information requesting application 10 a wants to 
information from an information providing application 
knowing where to find the information itself 
implementation it is supposed that communication with 
server means is provided by the access means 11 L int 
requesting application 10 x . The advantage of 
implementation is that a fast response is obtained 
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privacy network, i.e. from the central server means 
whether the requested transaction is possible, without 
to involve the access means 21± of the information 
application 20i (or the information providing applicati 
The load resulting from rejected transactions on the 
21x on the information providing side will be consider 
as compared to a case when the providing side is invo 
early stage. 
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access means 
ably reduced 
lved at an 
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10 Thus, when the information requesting application 10i 

information in, or get information from, an information 
O or holder, the requesting application lOi makes an 
towards "its" access means Hi- The requesting appl 
^ not know the address of the information provider, It 
if supposed that access means Hi holds a public key and 
key. The private key PKI (Private Key Infrastructure) 
yg may e.g. be stored as a key object, e.g. a secured obj 



y. In a particular , implementation the request is sent over RMI, and 
2 HI it preferably contains: 



the user identity (ID) associated with the request and used by 
the requesting application, 
a DTD Agreement Version, 
a DTD Agreement ID, 
a Transaction ID, 

an ID of the Requesting Application, 
a Gateway ID, and 
an XML Node Tree Container, 



ect 



s to set 
provider , 
request 
ion does 
is further 
a private 
of a node 
file. 



The XML Node Tree Container contains an XML (node) tree tagged 
with which information the requesting application wants to get or 
in which personal data he wants to set data, update da- 



a etc. The 
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tagged XML (node) tree is described as a form, an XML DOM node 
tree form. 

The XML Node Tree Container is an object for transportation of the 
XML Node Tree between the requesting application and its access 
means ll lm I indicates a request from the requesting application 
10i to the access means ll x . Access means 1^ finds the general DTD 
agreement file, a general XSLT file, the Public Key of the central 
server means, DNS (Domain Name Server) names and IP addresses (one 
or more IP number based URLs from the main central server means 
for the DTD agreement ID, in case there are more than one central 
server means) . 

The relevant information for central server means ID, agreement 
information etc. is fetched by the access means Hi from the 
associated database 12 2 * 

The access means ll x of the requesting application 10i then sends 
the request on, II, to the central server means 30i to find the 
DTD agreement. Particularly HTTPS is used, and the request 
particularly comprises : 

- the identity of the requesting application access means llj, 

- the digital signature of the requesting application access means 
with its private key, 

- the end user ID used by the requesting application 10i, 

- the DTD agreement version, 

- the DTD agreement ID, 

- the Transaction ID, 

- the Gateway ID, and 

- the requesting application id. 

A response is then awaited and expected from the central server 
means 30 x * 



The central server 31 lf which comprises control logic, checks the 
authentication of the request including the identity of the access 
means, the IP address (optionally) and the digital signature 
against the public key of the access means Hi. The requesting 
application user ID and the DTD agreement ID are then mapped onto 
the information providing application user ID. It should be noted 
that the user identity used by a requesting application can be, or 
normally is, different from the user identity used by an 
information providing application. Further, the user 
identification used by an application is not the identification of 
the application - 

The information providing application 20x user ID is encrypted 
with date/time using the public key of the access means 21i of the 
information providing application 20^, such that it only can be 
read and understood by the information providing application 
access means 21i- The encrypted pattern should be different every 
time the access means Hi of the requesting application 10i makes 
a request. The central server 31i gets a digital signature for the 
user unique DTD file from the database holding protection profile 
information 32i, signed with the private key of the central server 
means 31i. To obtain a good performance, all DTD-files are 
preferably signed in advance. "Out of band" information elements 
are also signed, (By "out of band" information is here meant the 
systems level communication layer, £»g- including control 
information for the access means. This can e.g. be implemented as 
HTTP POST in the forward direction and as a cookie in the backward 
direction. ) 

The central server means 31i then returns messages, III/ to the 
requesting application access means ll x containing the user unique 
DTD file as in-band information- (By "in-band" is here meant 
information at the application data communication layer, e.g. at 
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XML document level,) The central server means 31 x also returns 
"out of band" information such as : 

- the digital signature of the user unique DTD file, 

- the digital signature of the central server means "out of band" 
inf ormation, 

- the identity of the central server means, 

- the encrypted user ID, i.e. the information providing 
application user ID, 

- time to live, 

~ inactivity time, 

- response time, 

- the domain name of the access means 21i of the information 
providing application 20 lr 

- its IP address, and 

- the public keys of the respective access means Hi, 21i. 

If the DTD agreement ID version from the central server 31i does 
not correspond to the DTD agreement ID version from the requesting 
application 10i, an error notification will result and be logged. 
The transaction ID from the requesting application 10; (via its 
access means Hi) r the user ID of the requesting application, 10j 
and the encrypted user ID of the information providing application 
will be logged in the central server means 30 x . 

In the access means llj. of the requesting application 10 if the 
digital signature of the central server means 31i, with its public 
key, is authenticated. The requesting access means Hi will 
perform a transformation of the XML node tree to an XML transport 
file (string) with the general XSLT file (the XSLT file for that 
particular DTD agreement ID) (XSL Transformation; XSL is e.g. 
described in XSL Transformations (XSLT) Version 1.0, W3C Rec. 
dated 10 November 1999 and XSL Transformations (XSLT) Version 1,1 
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W3C Working draft, 12 December 200 0, which documents herewith are 
incorporated herein by reference) . 

The requesting application access means 11 L validates the received 
user unique DTD file against the XML transport file (string) . Next 
the XML-file will be signed- If there is a request for something, 
via an XML attribute, for which access is not allowed, an error 
message will be returned to the requesting application 10 x by one 
of the access means . 

if however the validation can be completed without errors, the 
g requesting application access means ll x sends, to the access means 
Cl 21i of the information providing application, IV, : 

:.rrt 

1£ y ~ the XML transport (string) (as in-band information) and out of 

m band information, e.g. in the form of a Cookie, i.e. the digital 

^ signature for the XML transport file (string) with the private 

H» key of the access means Hi, 

fn - the digital signature of the out of band information from the 

lit" 

2 ^fi central server means 30 X/ which means the server ID, 
O - encrypted user ID (user ID of the information providing 
application) , 

- time to live, 

- inactivity time, 
2 5 - response time, 

- the validation of the information providing side, 

- DTD agreement ID and DTD agreement ID version, and 

- the public keys of respective access means Hi, 21i. 

30 Not all digital signatures are necessary, some of them may be 
optional, depending on the degree of security that is demanded. 
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In the flow diagram of Fig. 4 is schematically illustrated how an 
XML form is used to request and provide data* In this 
implementation the object form of XML is implemented. 

It is first:, 100, supposed that an agreement between requesting 
application A4 and providing application B4 is established. (Of 
course an agreement may already be available , and may have been 
established at an earlier stage, this is not relevant for the 
functioning of the application, the main thing being that there is 
an established agreement) • Using the agreement, a DTD agreement is 
created defining which information is allowed to exchange between 
A4 and B4, 101. Similar to the preceding step, a DTD agreement may 
already be available. 

The DTD agreement is then used to build an XML form, here 
implemented as an XML DOM node tree object with attributes 
representing queries to be contained in the form, 102. 

In A4 the form is then filled in by giving relevant attributes the 
appropriate values as will be further illustrated below, 103. 
Subsequently the XML DOM node tree object, i.e. the filled-in form 
in object form, is transformed to an XML transport string , e*g~ 
using an XSLT, XSL style sheet, (Extensible Style Sheet Language) , 
104, The tagged XML node tree (i.e. tagged in that the attributes 
and element data are given values) is sent as an XML transport 
string to providing application B4, 105* On the providing side, 
i„e* on the side of B4 r the XML transport string is parsed to an 
XML object using XML DOM parser, 106. On the providing side the 
request of the XML form is also converted to a database call, e.g. 
of SQL format (Structured Query Language) , which is sent to the 
relevant database holding the information, 107. From the database, 
the requested information is then returned to B4, 108. The 
retrieved information is filled in on the XML DOM node tree (form) 
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by giving the attributes and element data the appropriate values 
according to the information from the database, 10 9. 

Subsequently the XML node tree object (form) is transformed to an 
XML transport string, e.g. using an XSLT as discussed above, 110. 
The XML transport string is returned to the requesting side 
comprising the requesting application A4, 111. 

In Fig. 5 an alternative implementation is illustrated in which 
the XML form is implemented and transported as a string. The steps 
f1 200, 201 relating to establishment of an agreement and creation of 
J3 a DTD agreement (or finding a DTD agreement) correspond to steps 
^ 100, 101 of Fig. 4, with the difference that the requesting and 
i~ providing applications in this embodiment are denoted A3 and B3 
1 SUi respectively . 

s The DTD agreement is here used to implement an XML tree as a 
5T str: *- ng w i th attributes representing queries to be contained in the 
fy form, 202. In the requesting application A3 the form is filled in 
by giving (assigning) values to the selected/relevant attributes 
(the appropriate values relating to the information to be 
requested), 203. The XML tree form, tagged in the described 
manner, is then sent (as a string) to providing application B3, 
204. In B3 the request of the tagged XML string is converted to a 
database call, e.g. of SQL format, using a SAX parser (SAX is 
Simple API for XML, which is an event based Application 
Programming Interface as opposed to the object based API as 
discussed with reference to Fig- 4), 205* The SQL request is sent 
to the relevant database holding the requested information, 206. 
When the information has been retrieved, it is transferred and 
received in B3, 207 4 in B3 the XML form is filled in (using SAX 
parser) with the requested information by giving the attributes 
and element data the appropriate values according to or 
corresponding to the retrieved information,, 208 . The completed, 
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i.e. filled in, XML form is then returned to A3 as an XML string 
209. 

In Fig. 6 a flow diagram is illustrated which substantially 
corresponds to the block diagram of Fig. 3 describing an 
embodiment including validation by means of a privacy protection 
network. It is thus, like in Figs. 4,5, supposed that there is, or 
has been, a step of establishing an agreement between, here, 
requesting application A5 and providing application B5, 300. in 
application A5 the relevant, basic XML form created using 
information on the agreement, e.g. a DTD, is, after fetching, 
filled in, 301. The XML form is then sent as an XML object file to 
the access means of A5, 302. In the access means of A5, the XML 
object file is converted to an XML transport string, e.g. using 
1 ij XSXjT ' 303 ' as also discussed above. When validation is performed, 
^|| the string format has to be used. The XML form (i.e. string) is 
j\ . then received in the access means of A5, and validated against a 
jU user unique DTD retrieved from a relevant central protection 
server holding means, 304 . During the validation step it is 
established if the XML string is valid, 305. If the XML string is 
not valid, this particularly means that the user unique DTD stored 
in the central protection server holder means is locked. 
Subsequently the request is not allowed, 305A. The user unique dtd 
stored in the central protection server holding means is 
particularly end user controlled, such that and end user 
lock/unlock the whole DTD or partially lock/unlock the DTD, 
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If on the other hand it is established that the XML string is 
valid, the request is sent as an XML transport string (preferably 
with the relevant DTD, which however is an option) to the access 
means of B5, which like the access means of A5 may comprise a so 
called server plug-in, 306. In the access means of B5 parsing 
using DOM parser of the XML string to an XML object is performed, 
307. The XML object is subsequently forwarded to application B5, 
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308. As described with reference to Figs. 4,5 the requested 
information is obtained from a database holding the requested 
information by means of an SQL database call, 309, to which the 
request has been converted, as described above. The retrieved 
5 information is entered on the XML form in application B5, 310. The 
XML form is subsequently sent as an object file to the access 
means of B5 wherein the XML object is transformed to an XML 
transport string, e.g. using XSLT, 311. Thereupon the XML 
transport string (optionally with DTD) is sent to the access means 
10 of R5 for forwarding to application AS, 312. 



For validation purposes digital signatures relating to user 
identities etc- may be performed in the respective access means 
'5 and in the central protection server- This is however not part of 
1|J the present application - 



~ For explanatory reasons an example on an XML form with queries, in 

H~ object form, may be as follows: 

2§e TestPrivacyBank. xml 

^ < *?xml version="l. 0" encoding="ISO-88 5 9-1 " standalone- n no" ?> 

p < ! — General XML — > 

< 1 — extern DTD 

25 <!DOCTYFE Privacy SYSTEM "TestPrivacyBank. dtd" > 



< Privacy > 
< Bank > 

30 < BankName BankName = "from" > Nordbanken < /BankNaine > 

< CustNumber CustNumber»"f rom" > 1234 < /CustNumber > 
< Phone Phone-" from" > 0858500000 < /Phone > 
< Mobile Mobile="f rom" > 0702555555 < /Mobile > 
< Email Email=" f rom" > peter . xxxxxSxxx . erics son , se < /Email > 

3 5 < Account s> 

< Current Current="get" > < /Current > 

< LocalCurrency LocalCurrency=' r get" > < /LocalCurrency > 

< ForeignCurrency ForeignCurrency= f, get" > < /ForeignCurrency > 

< TimeDeposit TimeDeposit="get " > < /TimeDeposit > 
40 < stock Stock="get"> < /Stock > 

< Fund Fund="get" > < /Fund > 
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< /Accounts > 
< /Bank> 
< /Privacy > 

5 This XML form is not visible (readable) since it is in object 
form. Attributes which can be given values are "from", "get". The 
XML form in object form is sent from requesting application <A5) 
to its aczc&ss means. Below a DTD for an XML form is shown, i.e. 
the basic form with an illustration of attribute selections which 
10 are possible: (This shows the basic form, after communication with 
the central protection server has taken place) . 



yo TestPrivacyBank. dtd 

lf£ <• — general DTD — > 

attribute selections 

from (input data to Application B database for pull data) 
get (get data from Application B database for pull data) 
null (element provides no data, don T t care) 
error (returned: ELEMENT contains error) 
set (set the value, for push data) 
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|I < ! ELEMENT Privacy (Bank*) > 

< I ELEMENT Bank (BankName, CustNumber, Phone?, Mobile?, Email?, 

Accounts) > 

ELEMENT BankName (# PCDATA) > 

ATTLIST BankName BankName (from | error) # REQUIRED > 

ELEMENT Cu 3 t Number (# PCDATA) > 

ATTLIST CustNumber CustNumber (fromj null | error) # REQUIRED > 

ELEMENT Phone (# PCDATA) > 

ATTLIST Phone Phone ( from) null | error) # REQUIRED > 

ELEMENT Mobile (# PC DAT A) > 

ATTLIST Mobile Mobile (fromj null | error ) # REQUIRED > 

ELEMENT Email (# PC DATA) > 

ATTLIST Email Email ( from | null | error ) # REQUIRED > 

40 <! ELEMENT Accounts (Current?, LocalCurrency, ForeignCurrency? 
TimeDeposit?, Stock?, Fund?) > 

< ! ELEMENT Current (# PCDATA) > 

< ! ATTLIST Current Current (get | null | error [ set ) # REQUIRED > 

4 5 < ! ELEMENT LocalCurrency (#PCDATA) > 



< 

30 < 
< 
< 
< 
< 

35 < 
< 
< 
< 
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< 
< 
< 
< 

10 < 
< 



# REQUIRED ^ ocalCurrenc y LocalCurrency (get | null [ error | set ) 

< ! ELEMENT ForeignCurrency (#PCDATA) > 

< IATTLIST ForeignCurrency ForeignCurrency (get I null I error I set ) 
# REQUIRED > 111/ 

ELEMENT TimeDeposit (#PCDATA) > 

ATTLIST TimeDeposit TimeDeposit (get | null I error I set ) #REQUIRED > 
ELEMENT Stock (# PCDATA) > 

ATTLIST Stock Stock ( get | null | error | set ) # REQUIRED > 
ELEMENT Fund (# PCDATA) > 

ATTLIST Fund Fund (get I null | error | set } # REQUIRED > 



l^U Below is also shown an XSLT for transformation of the XML form in 
WQ object format to string format (required for communi cation with 
the central protection server and for communication between 
j£ applications) . 

TestprivacyBank.xsl 
y < ?xml vers±on="1.0 fl encoding-"ISO-88 59-1" standalone="yes " ? > 

J** <xsl: stylesheet xmlns : xsl="http : //www. w3 . org . /1999/XSL/Transf orm" 

ver sion=" 1.0" > 
*U . <xsl: output method="xml n indent="yes"/ > 

O < xsl: template match=" / Privacy" > 

< Privacy > 
30 <Bank> 

< xsl : f or-each select="Bank/BankNarne" > 

< BankName >< xsl: attribute name="BankName " >< xsl : value-of 
select="@BanklSlame"/ >< /xsl: "attribute >< xsl: value-of select-" . "/ >< /B 
ankName > 
35 < /xsl : for-each > 

< xsl : for-each select="Bank/CustNuniber" > 

< CustNurnber >< xsl : attribute nanie="CustNuniber " >< xsl: value-of 
select="@CustNumber"/ >< /xsl : attribute >< xsl : value-of select=" . "/ > 

4 0 < /CustNurnber > 

< /xsl : for-each > 

< xsl : for-each select="Bank/Phone n > 

< Phone >< xsl : attribute name="Phone" >< xsl : value-of 

45 select^"(§Phone"/ >< /xsl : attribute >< xsl : value-of select=". "/ > 
< /Phone > 
< /xsl : for-each > 
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< xsl : f or-each select="Bank/Mobile" > 

< Mobile >< xsl: attribute name= "Mobile" >< xsl: value-of 
select^" @Mobile" / /xsl : attribute >< xsl : value-of select-" " / > 
< /Mobile > 
< /xsl :f or-each > 

< xsl : f or-each select="Bank/Email" > 

< Email >< xsl : attribute name= ,f Email" >< xsl : value-of 
select="(a Email"/ >< /xsl : attribute >< xsl : valae-of select-" " / > 
< /Email > 
< /xsl : f or-each > 



< Accounts > 

15 < xsl :f or-each select-"Bank/Accounts /Current " > 

< Current >< xsl ; attribute name= "Current" >< xsl : value-of 
D s elect^"@ current"/ >< /xsl : attribute >< xsl : value-of select=" . "/ > 
Ji < /Current > 

< /xsl : f or-each > 



; xsl : f or-each select=*"Bank/Accounts/LocalCurrency" > 



< LocalCurrency >< xsl : attribute naiue-"LocalCurrency" >< xsl : value- 
s el ect-" @Loca lCurr ency " / >< /xsl : attribute >< xsl : value-of select^"."/ 

2m > 



of 



s < /LocalCurrency > 
jMf < /xsl : f or-each > 

ssssSss 

fy < xsl :f or-each select="Bank/Accounts/ForeignCurrency" > 
3% < For eignCurr ency >< xsl : attribute name="ForeignCurrency" > 

< xsl: value-of select="@ForeignCurrency"/ >< /xsl : attribute >< xsl : 
f: value-of select=" . "/ >< /ForeignCurrency > 
r " < /xsl : f or-each > 

35 < xsl: f or-each select-"Bank/Accounts/TirneDeposit " > 

< TimeDeposit >< xsl: attribute name= ir TimeDeposit" >< xsl : value-of 
select-"@TimeDeposit"/ >< /xsl ; attribute >< xsl: value-of select-" . "/ > 
< /TimeDeposit > 
< /xsl : f or-each > 



< xsl : f or-each select="Bank/Accounts/Stock" > 

< Stock >< xsl : attribute name= n Stock" >< xsl : value-of select = 
,r @Stock"/ >< /xsl: attribute >< xsl: value-of select-" . "/ > < /Stock > 
< /xsl : f or-each > 
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The DTD as described above is provided from the central protection 
server to the access means of the requesting application and 
actually results from the XSLT as described above. 

The XML form in object form and the DTD will result in an XML form 
with queries, as can be seen below: 



TestPrivacyBankTransport . xml 

< ?xml version-" 1.0" encoding="ISO-8 8 5 9-l" standalone="yes"? > 
10 < ! — XML transport file with example data — > 

O < ! DOCTYPE Privacy 

© [ 

;jj < [ ELEMENT Privacy (Bank-H) > 
l|| < ! ELEMENT Bank (BankName, CustNumber, Phone?, Mobile?, Email?, 
p Accounts) > 

iji < [ ELEMENT BankName (#PCDATA) > 

"1 < ! ATTLXST BankName BankName (from] error) #R£QUIRED > 
% < I ELEMENT CustNuinber ( # PC DATA) > 
2** <! ATTLIST CustNumber CustNumber (from) null | error) # REQUIRED > 
f < ! ELEMENT Phone (# PCDATA) > 

1^ < ! ATTLIST Phone Phone ( from | null | error ) # REQUIRED > 

< I ELEMENT Mobile {# PCDATA) > 

fU <! ATTLIST Mobile Mobile ( from| null [ error) #REQUIRED> 
2ffl <! ELEMENT Email (#PCDATA) > 
O < \ ATTLIST Email Email (from| null | error) # REQUIRED > 

< ! ELEMENT Accounts (Current?, LocalCurrency, ForeignCurrency?, 
TimeDeposit?, Stock?, Fund?) > 
< ! ELEMENT Current (# PCDATA) > 
30 <! ATTLIST Current Current (get | null [error | set) # REQUIRED > 

< I ELEMENT LocalCurrency (#PCDATA) > 

<! ATTLIST LocalCurrency LocalCurrency (get | null J error I set ) 
#REQUIRED> 

< ! ELEMENT ForeignCurrency (#PCDATA) > 
35 < I ATTLIST ForeignCurrency ForeignCurrency (get I null I error I set ) 
# REQUIRED > 

< ! ELEMENT TimeDeposit (# PC DATA) > 

< I ATTLIST TimeDeposit TimeDeposit (get | null | error | set ) # REQUIRED > 
< ! ELEMENT Stock (# PCDATA) > 

40 <! ATTLIST Stock Stock (get | null | error | set ) # REQUIRED > 

< I ELEMENT Fond ( # PCDATA) > 

< ! ATTLIST Fond Fond (get I null I error I set ) # REQUIRED > 
] > 



28 

< Privacy > 
< Bank > 

<BanklSIame BankName="from"> Nordea < /EankName > 

< CustNumber CustNumber="null" > < /CustNumber > 

< Phone Phone-"from ,i > +46858500000< /Phone > 
<Mobile Mobile="null' T > < /Mobile > 

< Email :&rLail=="null" > < /Email > 

< Accounts > 

< Current Current="get" > < /Current > 

< LocalCurrency LocalCurrency= fr get " > < /LocalCurrency > 

< ForeignCurrency ForeignCurrency= ,, null" > < /ForeignCurrency > 
<TimeDeposit TimeDeposit="null" > < /Time Deposit > 

< Stock Stock="null" > </Stock> 
< Fund Fund="null" > </Fund> 
< /Accounts > 
< /Bank> 
< /Privacy > 



The first part is the DTD, and the second is the XML form as 
f illed-in. 

This is what is sent from the access means of the requesting 
application to the providing application, after validabion (if 
implemented) . 

As can be seen, information is wanted about current account (the 
attribute "get") and also about local currency (attribute "get") . 
The others are "null" (except for the phone number of the 
requester) . 

Thus, above the queries and the DTD are shown. This is validated, 
and if the validation is successful, the above XML form (with DTD) 
is sent from the access means of the requesting application to the 
access means of the providing application, which in turn requires 
the requested data from a database as discussed earlier in the 
application. When the form has been filled in using the retrieved 
information,- a response is returned from the access means of the 
providing application to the requesting application: 

TestPrivacyBankTransportReturn,xial 
<?xml version="l . 0" encoding="ISO-8859~l"?> 
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<! — extern DTD 

<1D0CTYPE privacy SYSTEM "TestPrivacyBank . dtd"> 

5. 

<Pr±vacy> 
<Bank> 

<BankName BankName= n from"> Nordea </BankName> 
<CustNumber CustNumber="null"> </CustNumber> 
10 <Phone Phone="from"> +468585000000 </Phone> 

<Mobile Mobile="null ,r > </Mobile> 
<Email Email="null"> </Email> 
<Accounts> 
<Current Current="get"> 25 6 </Current> 
15 <LocalCurrency LocalCurrency= r, get' r > 512 </LocalCurrency> 

^ <TimeDeposit TimeDeposit— w null w > </TimeDeposit> 

% <Stock Stock^"null"> </Stock> 

*y <Fund Fund= ,T null"> </Fund> 

■%T < /Ac c o unt s > 
2Q0 </Bank> 
# </Privacy> 

,10 Optionally the DTD is included, this is however not illustrated. 
25 

U As far as validation is concerned, below a DTD which is locked 
5? (blocked) is illustrated. Particularly this is stored in the 
Jj. central server means. Particularly it is used for validation of 
the XML object. 

30 

It can be established that there is no correspondence between 
the attribute values. Thus it can be concluded that the XML form 
query is not valid. 

35 Blocked DTD: 

TestPrivacyBankEndUserLock, dtd 
<! — End User DTD example with lock — > 

40 <! — 

selection 



from (fromput data to Application B database for pull data) 
get (get data from Application B database, for pull data> 
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null (element provides no data, don't care) 
error (returned: ELEMENT contains error) 
set (set the value, for push data) 

<! ELEMENT Privacy (Bank+)> 

< I ELEMENT Bank (BankName, CustNumber, Phone? Mobile? Email?, 
Accounts ) > 



< I ELEMENT BankName (# PC DATA) > 

< I ATTLIST BankName BankName (from [ null | error ) # REQUIRED > 

<" ELEMENT CustNumber (#PCDATA)> 

< 1 ATTLIST CustNumber CustNumber (froml null 1 error) #REQUIRED > 

15_ <" ELEMENT Phone (#PCDATA)> 

C3 < I ATTLIST Phone Phone (£rozn| null I error) # REQUIRED > 

m <" ELEMENT Mobile (#PCDATA) > 

m < I ATTLIST Mobile Mobile (from| null | error) # REQUIRED > 

C <" ELEMENT Email (#PCDATA)> 

2Qp <! ATTLIST Email Email ( from | null | error ) # REQUIRED > 

? r d < 1 ELEMENT Accounts ( Current?, LocalCurrency, ForeignCurrency? , 
^ TimeDeposit?, Stock?, Fund?)> 

<! ELEMENT Current (# PCDATA) > 

l2 '< 'ATTLIST Current Current (null | error) # REQUIRED > 

<! ELEMENT LocalCurrency (#PCDATA)> 

*Jf <l ATTLIST LocalCurrency (null (error) # REQUIRED > 

Jjj <! ELEMENT ForeignCurrency (#PCDATA)> 

34J <! ATTLIST ForeignCurrency ForeignCurrency (null I error) 

U # REQUIRED > 

< ! ELEMENT TimeDeposit (# PCDATA) > 

< ! ATTLIST TimeDeposit TimeDeposit (set I null I error ) # REQUIRED > 

<! ELEMENT Stock (#PCDATA)> 

35 < ! ATTLIST Stock Stock (null (error) # REQUIRED > 

< ! ELEMENT Fund ( # PCDATA ) > 

< I ATTLIST Fund Fund (null) error) # REQUIRED > , 



and the XML file validated against the locked DTD, resulting in 
invalidity: 



45 TestPrivacyBankEndUserlock. xml 

<?xml version-"!. 0" encoding-" ISO-8 859-1" standalone="no" ?> 
<! — This is an XML demo of locked end user — > 
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<! — extern DTD 

<!DOCTYPE Privacy SYSTEM "T^tPrivacyBankEndUserlock. dtd"> 



5 <Privacy> 
<Bank> 

<BankName BankName="f rom"> Nordea </BankName> 
<CustNumber CustNumber= r, f rpm"> </CustNumber> 
<Phone Phone="f rom"> </Phone> 
10 <Mobile Mobile="from n > +46702670652 </Mobile> 

<Email Email-" from n > </Email> 
<Accounts> 
<Current Current =" get "> </Current> 

<LocalCurrency LocalCurrency-"null"> </LocalCurrency> 
15 <ForiegnCurrency ForeignCurrency«"get"> </ForeignCurrency> 

fi <TimeDeposit TimeDeposit-"set"> 12345 </TimeDeposit> 

% <Stock Stock="get"> </Stock> 

<Fund Fund-" get "> </Fond> 
^ < /Account s> 
2(P </Bank> 
4h </Privacy> 



€l Correspondingly an unlocked DTD and the XML form validated 
2 lL - a 9 ainst the unlocked DTD are examplif led as: 



<!■ 



Test PrivacyBankEndUserUnlock . dtd 
End user DTD example with unlocked data — > 



<! — 

selection 

35 from (fromput data to Application B database for pull data) 

get (get data from Application B database, for pull data) 

null (element provides no data, don't care) 

error (returned: ELEMENT contains error) 

set (set the value, for push data) 
40 — > 

<ELEMENT Privacy (Bank?)> 

45 <! ELEMENT Bank (BankName, CustNumber, Phone?, Mobile? Email?, 
Accounts) > 



< I ELEMENT BankName (# PCDATA) > 
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< ! ATTLIST BankName BankName ( from I null I error ) # REQUIRED > 
<! ELEMENT CustNumber (# PCDATA) > 

< ! ATTLIST CustNumber CustNumber (front| null I error } # REQUIRED > 
< I ELEMENT Phone <#PCDATA)> 

< ! ATTLIST Phone Phone ( from | null I error) # REQUIRED > 
<] ELEMENT Mobile (# PCDATA) > 

<! ATTLIST Mobile Mobile (from) null I error ) # REQUIRED > 
<i ELEMENT Email (#PCDATA>> 

< ! ATTLIST Email Email (f rom| null | error) # REQUIRED > 

<! ELEMENT Accounts { Current?, LocalCurrency, ForeignCurrency 
TxmeDeposit?, Stock? , Fund?)> 

< I ELEMENT Current (# PCDATA) > 

1 ^ st < ! ATTLIST Current Current (set | get | null | error ) #REQUIRED > 

y <! ELEMENT LocalCurrency (#PCDATA)> 

m < I ATTLIST LocalCurrency LocalCurrency (set I get I null I error ) 

# REQUIRED > 

tfl < 1 ELEMENT ForeignCurrency (# PCDATA) > 

2Qp <! ATTLIST ForeignCurrency ForeignCurrency (set I get i null I error ; 

hi #REQUIRED > 

ly < ! ELEMENT TimeDepos it (# PCDATA) > 

m < ! ATTLIST TimeDeposit TimeDeposit ( set 1 get I null I error ) 

, # REQUIRED > 

2$^ <! ELEMENT Stock (#PCDATA)> 

^ <! ATTLIST Stock Stock ( set | get | null | error ) # REQUIRED > 

l u <! ELEMENT Fund (#PCDATA)> 

j|j <! ATTLIST Fund Fund ( set | get | null | error ) # REQUIRED > 

^ TestPrivacyfiankEndUserUnlock . xml 

<?xml version-"1.0" encoding="lSO-8859-l I,f standalone="no" ?> 
<I — This is an XML demo of unlocked end user --> 

35 <! — extern DTD 

<!DOCTYPE Privacy SYSTEM "TestPrivacyBankEndUserUnlock . dtd"> 
— > 

<Privacy> 
4 0 <Bank> 

<BankName BankName ="from"> NORDEA </BankName> 
<CustNumber CustNumber-" from'" > 12345 </CustNumber> 
<Phone Phone = Tt null"> </Fhone> 
<Mobile Mobile="null"> </Mobile> 
45 <Email Email-" f rom"> eraxxxx@eip.ericsson.se </Email> 

<Accounts> 
<Current Current="get"> </Current> 

<LocalCurrency LocalCurrency- " get " > </LocalCurrency> 
<ForeignCurrency ForeignCurrency="set I *> 1234 
50 </ForeignCurrency> 
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<TimeDeposit TimeDeposit="set"> 1234 </TimeDeposit> 
<Stock Stock«"null"> </Stock> 
<Fund Fund="null"> </Fund> 
</Accounts> 
5 </Bank> 
</Privacy> 



It should be clear that, of course the invention is not limited 
10 to the specifically illustrated embodiments, but that it can be 
varied in a number of ways within the scope of the appended 
claims - 




